Method of and apparatus for forecasting the price of a commodity

ABSTRACT

A pricing engine that automatically forecasts a price of a tradable commodity so that a quote price can be generated that will remain valid for a pre-defined time window. The pre-defined time window is typically a short time interval which is long enough for the user to evaluate the price and trade on it if required. In one implementation, the pricing engine forecasts what the price is likely to be at the end of the pre-defined time window and that forecasted price is then used as the basis for the quote price.

REMARKS

This application is a National Stage filing of PCT applicationPCT/GB02/01911 filed on Apr. 24, 2002. Claims 1-41 have been cancelledand replaced with claims 42-82 to remove the multiple dependencies andplace the application in a more acceptable form for examination. TheU.S. Patent Office is hereby requested to examine the application basedupon the substitute specification and claims. If the patent examiner hasany questions or comments, he is respectfully requested to contactapplicant's attorney at the telephone number indicated below so thatadditional amendments may be added as required.

FIELD OF THE INVENTION

This invention relates to a method of and apparatus for forecasting theprice of a commodity. It finds application in pricing engines used toprice tradable commodities.

DESCRIPTION OF THE PRIOR ART

Network based transaction platforms are widely-used for trading a broadrange of commodities at fluctuating prices. Conventional platforms quotetwo different kinds of prices: first, guide or indicative prices. Theseare approximate, non-legally binding and meant to give a rough idea ofthe price that would be available to trade at. If an end-user (sometimesreferred to as a ‘party’ or a ‘client’) wishes to actually trade acommodity (i.e. buy or sell), then he will send a request for a quote(or ‘RFQ’) which fully defines the required trade (e.g. commodity,amount, tenor etc.) to the transaction platform provided by a bank orother kind of financial institution. The RFQ may pass through or beinitiated by a portal. The RFQ will be sent for credit vetting (i.e. toensure that the end-user has sufficient credit to conduct the trade) andthen to a pricing or quoting engine to give a second kind of price—afirm and legally binding price. This price is sometimes called an‘execution’ price, since an end-user can execute a trade at that price.This firm price is communicated to the end-user via the network and theend-user can either proceed with it (e.g. hit a ‘buy’ (or ‘sell’) key ontheir terminal) or ignore it. Proceeding constitutes an offer to trademade by the end-user; this offer is then sent to the transactionplatform over the network. If the offer is received quickly enough, itmay be accepted by the platform and the trade will then be carried out.But if the end-user has been too slow in responding, or if the ‘buy’ (or‘sell’) message has been slowed down because of latency (e.g. inherentnetwork latency or heavy congestion or any other process which slowsdown message process, such as credit checking) then it may reach thetransaction platform after the price has changed; the transactionplatform will then refuse to proceed further. This is especiallyfrustrating to end-users trading over the public internet using webbased transaction platforms at times of rapidly falling prices—end-userswill place trades to sell at the price quoted at one instant, only fortheir sell order to be rejected because by the time it is received atthe transaction platform, the price has altered. The same problem arisesat times of rapidly rising prices.

A conventional auto-pricing engine determines price using a number offactors, including the identity of the end-user, the size of thetransaction, its tenor, the applicable trader spread and salespersonspread. But conventional pricing engines calculate prices based on themost recent live data only: as explained above, at times of rapidlychanging prices, this inevitably leads to new prices being automaticallygenerated and supplied so quickly that an end-user does not have enoughtime to properly evaluate the price or even to capture a trade at adisplayed price, since his order will be received by the transactionplatform after that price has been replaced by a new price.

Two further examples will illustrate this problem. When an end-userwishes to trade on a web based portal which collects pricing data fromseveral sources (e.g. FXall and Currenex for foreign exchange), theportal can operate a ‘fast quote’ system, in which it typically sendsout a RFQ to e.g. 5 participating banks and then displays each of the 5prices, updated in real time. Since each price may change every secondor so (more rapidly still at times), the challenge facing an end-user isone of identifying and selecting the best deal almost instantly; thischallenge is quite considerable, even for professional users. For lessexperienced end-users, particularly retail users or smaller corporatetreasury departments (exactly the kinds of users who might most benefitfrom a web based FX trading system), the challenge is an extreme one.

The ‘reverse auction’ approach is meant to address this problem. In areverse auction, the portal sends out a RFQ to e.g.5 participating banksif an end-user needs an execution price; each bank then has e.g. 25seconds to release a price. That price is meant to be firm for e.g. 5seconds, in order to give the end-user enough time to consider and tradeat that price if he wishes. However, if a bank's price changes duringthis 5 second period, the quote auto-terminates. Hence, there is noguarantee to an end-user that any quote will in fact definitely beavailable to trade on for the full 5 seconds. Again, at times of fastmoving prices, the likelihood is that the prices will not remain stablefor 5 seconds, again denying end-users the ability to trade at criticaltimes, such as market crashes.

The unreliability of legally binding execution prices has beenconsidered above. But the unreliability of even indicative rates isproblematic too since (a) it implies that execution prices will besimilarly unreliable and (b) it gives the impression that the entiredealing process is opaque. This is particularly problematic for webbased trading systems aimed at appealing to a wide base of end-users.

Reference may also be made to pricing models which predict future pricesover a much longer time period of typically days or weeks. These kindsof pricing models are however of limited relevance to the presentinvention since they apply forecasting techniques to predict a specificprice in the future to identify buying and selling opportunities. Incontrast, the present invention addresses the particular problem oftypically short-term price volatility which in the past has meant thatprices can alter too rapidly to allow trades to be completed at a quotedprice.

SUMMARY OF THE PRESENT INVENTION

In a first aspect of the present invention, there is a pricing enginethat automatically forecasts a price of a tradable commodity so that aquote price can be generated that will remain valid for a pre-definedtime window. In one implementation, the pricing engine forecasts whatthe price is likely to be at the end of the pre-defined time window andthat forecasted price is then used as the basis for the quote price.Volatility and non-volatility related spreads may be applied to theforecast price to generate an actual quote price.

The pre-defined time window is typically a short time interval which islong enough for the user to evaluate the price and trade on it ifrequired As explained in the prior art section, auto-generated pricesthat are guaranteed to remain fixed for a given time period are notknown: instead, prior art systems offer only prices which eitherfluctuate as live prices change (the ‘fast quote’ system) or elseterminate when live prices change (the ‘reverse auction’ system). In aspot FX implementation, for example, a 10 second pre-defined time windowmay give a guaranteed stable 6 seconds ‘trading window’ at the end-userterminal, taking into account the time it takes a message to be sentfrom the pricing engine/transaction platform to the end-user and backagain.

To date, no-one has appreciated the possibility of applying priceforecasting techniques to allow a quote price to be automaticallygenerated and remain valid (i.e. remain acceptable by a transactionplatform) over a pre-defined time window long enough to allow a user toconsider a trade and for that order to be received and accepted at thetransaction platform. This has occurred despite the widespread criticismdirected at many web based commodity trading systems because they failedto allow end-users to complete trades during turbulent price events(e.g. major corrections) and hence locked out users at the very timethey were most anxious to trade.

A major barrier to even appreciating the possibility of auto-forecastingprices to give quotes a guaranteed, valid trading window of (typically)several seconds is that this is not a core skill practised by evenexpert currency traders. In theory, an expert currency trader might feelable to ‘intuit’ an appropriate price to quote a client if he knows thatthe client will take up to 10 seconds to respond because of networkcommunications latencies etc, but in practice the expert trader isactive on networks with minimal latency and would not be exposinghim/herself to the additional risk undertaken when quoting a valid priceover a slow connection. There is therefore no published theoreticalunderstanding of the factors that might be applied by a trader in thesecircumstances, in part also because the skills of an expert trader areused for far more sophisticated tasks, such as reacting to macroeconomictrends (e.g. political events, company reports, analysts' reports etc),‘reading’ the customer—e.g. moving a price down due to the trader'sbelief that the customer may be a seller, and ‘quoting against yourposition’—e.g. moving a price up to increase the likelihood that thecustomer may sell, in the event that the trader may wish to reduce ashort position.

In contrast, the present invention forecasts price by monitoring theusually small price fluctuations caused by the rapid, transient changesin supply and demand for the purpose of enabling a price quote to bepublished to an end-user which can be guaranteed to remain valid for apre-defined time which is selected to be long enough for the end-user toadequately consider and trade at that price. Equally important, is thatthe present invention allows for multiple quotes to be constantly (e.g.every 6 seconds a customer receives a new price valid for a further 6seconds) given in multiple currencies over multiple tenors,simultaneously, to a bank's entire client base—a feat impossible toreplicate with human resource alone.

In one implementation of the present invention, the pricing engine mayapply a curve extrapolation algorithm to forecast the price, thealgorithm using a weighted gradient formula to increase the significanceof the rate of change of very recent prices compared to less recentprices.

The algorithm may be functionally equivalent to the following algorithm:$P_{n + 1} = {\left( {1/\left( {2^{n - 1} - 1} \right)} \right) \times \left\lbrack {{\left( {{3 \times 2^{n - 2}} - 1} \right)P_{n}} - \left( {\sum\limits_{i = 1}^{n - 2}{2^{n - i - 2}P_{n - 1}}} \right) - P_{1}} \right\rbrack}$where P_(n+1) is the forecast price at time t_(n+1) as derived from anextrapolation of the changing live market prices P₁ . . . P_(n) measuredat regular time intervals t₁ . . . t_(n).

In a spot FX implementation via a third-party portal, it has been foundthat forecasting 10 seconds into the future is suitable. That is becausefor some FX portals, the typical time it takes a message to be sent fromthe transaction platform to the portal and then on to the end-userterminal is approximately 2 seconds (with minimal latency betweentransaction platform and portal when operating over 128 kbps E1/T1circuits) and the same amount of time is taken for the return path.Hence, the pricing engine is regularly forecasting a price 10 seconds inthe future and the forecasted price is valid (i.e. forms the basis of aquote price that can be accepted) for the whole of that 10 seconds. A 10second fixed time period gives an approximate 6 second ‘tradingwindow’—i.e. a period of 6 seconds for the customer (via the portal) toactually decide whether to trade and to hit the buy (or sell) key. Theprice forecasting process is now repeated every 6 seconds, thereforeensuring that the customer (via the portal) has a price valid for 6seconds, after which time the customer receives an updated price againvalid for a further 6 seconds, and so on. It is also possible to monitorand compensate for substantial latency in the portal to end-userlink—for example, if the network is a mobile communications network(e.g. 3G) then the latency may be significant. A longer fixed timeperiod would be needed in these circumstances.

The preferred form of algorithm for FX spot tracks price changes fromconventional real time FX price feeds and then defines a curve in whichthe interpolated historic price is taken at e.g. 6 second intervals,looking back e.g. 60 seconds in total. From this curve, the future price6 seconds later is extrapolated. A progressive weighting is applied tothe gradient (rate of change of price) between the price at each 6second point, with each gradient given twice the weighting of theprevious gradient (i.e. the gradient to the previous price point).

However, the most recent price gradient is more important than precedingprice gradients and its weighting is tripled. Apart from the rate ofchange of the price, other measures may be relevant and usefulparameters to model, such as speed of rate of change and curvature.

In an implementation for spot FX trading, an accuracy of over 99.4% hastypically been achieved using 60 seconds of data to produce a 6 secondtrading window, meaning that only 5 quote prices in 1000 present anyarbitrage opportunities during the 6 second period. Hence, the presentinvention allows quote prices to be guaranteed over a time window whichis genuinely long enough to benefit end-users, without exposing thecounterparty (i.e. bank etc.) to a significantly high risk of an adverseprice movement making a trade unprofitable.

Because implementations of the present invention generate a short termprice forecast (e.g. for the next 6 seconds in the case of spot FX via aweb-site, or for the next 10 seconds via a third-party portal) usinglive pricing data obtained from market sources, significantmacro-economic influences to prices are reflected in the incoming dataanyway. The forecast price generated by the pricing engine will hencefollow the general trends in the market. Further, volatility isconstantly measured—e.g. the largest price differential (range) betweenregular time periods, such as every 6 seconds for the last 60 seconds,and this range is assumed to apply to the forecast price. Hence, ifthere is a significant event which causes the buy price of a commodityto rise sharply, the pricing engine will immediately notice and weightheavily the rate of price increase in the most recently measured 6second period when calculating the forecast price, applying theappropriate range.

Other key features of implementations are:

-   -   An end-user's terminal displays a clock which shows the        remaining time left for which the quote price will still be        valid or the elapsed time for which the quote price has been        valid.    -   The pricing engine increases the spread for longer pre-defined        time windows to compensate for the decreased accuracy of the        forecasted price and hence the increased risk incurred by a        counterparty trading with an end-user at the quote price.    -   The pricing engine increases the spread for smaller amounts to        be traded by an amount calculated to absorb transaction costs        and deliver a profit on even ‘micro FX’ trades (e.g. USD50K        worth or less)    -   Trader intervention to a spread that has been automatically        calculated using the volatility apparent from the historic        pricing data is readily achieved by allowing a scaling factor to        be applied to the spread.

Other aspects of the present invention are:

-   -   A method of providing a quote price for a tradable commodity, in        which the quote price (a) has been automatically generated using        a forecast price calculated by a pricing engine and (b) remains        valid for a pre-defined time window and (c) is supplied to an        end-user over a network.    -   A computer terminal displaying a quote price of a tradable        commodity, in which the quote price (a) is supplied over a        network to the terminal and (b) is based on a forecasted price        (automatically generated by a pricing engine) that will remain        valid for a pre-defined time, and in which the terminal displays        the remaining time for which a given quote price will remain        valid and/or the elapsed time for which the quote price has        remained valid.    -   A method of trading a commodity comprising the steps of:        -   (i) viewing at an end-user terminal a quote price that (a)            has been generated using a forecast price calculated by a            pricing engine and (b) can be traded on so long as a trade            order is received at a transaction platform during a            pre-defined time window and        -   (ii) placing an order at the quote price;        -   (iii) receiving the order at a transaction platform within            the pre-defined time window.    -   A system for trading commodities comprising (i) a pricing engine        which forecasts a price of a tradable commodity so that a quote        price can be generated that will remain valid for a pre-defined        time window; (ii) end-user terminals that can display the quote        price and allow end-users to place trades and (iii) a network        interconnecting the pricing engine and the end-user terminals.    -   Quote price data that (a) has been generated using a forecast        price calculated by a pricing engine and (b) remains valid for a        pre-defined time window and (c) is supplied to an end-user over        a network.

BRIEF DESCRIPTION OF THE DRAWINGS

An implementation of the present invention will be described withreference to the accompanying drawings. The implementation is from INGBank N.V. of London, United Kingdom and is called the PriceLock™auto-pricing system. PriceLock™ is part of an electronic FX tradingplatform called the eFX™ system. The accompanying drawings show thefollowing:

FIG. 1 is a high level architecture diagram of the eFX system;

FIG. 2 is a screen shot of the ‘Price Control Sheet’ window from acomputer terminal used by a trader to monitor and manage the eFX system;

FIG. 3 is an eFX ‘Dealer Spread Sheet’ window;

FIG. 4 is a typical FX Spot dealer's screen, showing multiple eFXwindows;

FIG. 5A is a graph showing how prices are measured and used to constructa forecast price with the PriceLock engine;

FIG. 5B is a timing diagram relating how regularly generated forecastprices relate to the trading windows displayed on a terminal using thePriceLock system;

FIG. 6 is an eFX ‘Market Sheet’ window, pre-populated with indicative FXprices;

FIG. 7 is an eFX ‘Order Capture’ window;

FIG. 8 is an eFX end-user/customer screen during a trade which has beensent to dealer intervention;

FIG. 9 shows a complete eFX trade history search for all users;

FIG. 10 shows an eFX Price Service Info Sheet, giving auto-pricingengine audit and analytics.

DETAILED DESCRIPTION

The present invention will be described with reference to animplementation from ING Bank N.V. of London, United Kingdom called thePriceLock™ auto-pricing system. PriceLock™ is part of an electronic FXtrading platform called the eFX™ system.

Business Overview

Financial institutions are moving business on-line. More efficient useof existing technology is granting those banks with automatic pricingengines a huge advantage in the field of foreign exchange. Recentexperience of trading on the multi-bank portal Atriax had shown thatcustomer requests for quote (RFQs) were being answered, transacted, andconfirmed by proprietary auto-pricing engines in less time than it takesa human sales representative to even acknowledge the request. Theproprietary ING eFX system incorporates the advanced PriceLock™auto-pricing engine and the customer and dealer screens required formultiple internet/intranet price-making and price-taking.

ING customers can trade FX on an ING web-site over the public internet,and on third party platforms via public internet and virtual privatenetworks. Trades are automatically pre-checked for the existence ofadequate counterparty limits, and delivered automatically into thedeal-capture system, thus facilitating straight-through-processing. Thissystem also turns ‘micro-FX’ into revenue, whereas before it representeda processing cost, and enables the efficient re-use of common ITcomponents. FIG. 1 is a high level architecture diagram of the eFXsystem showing the core components. These include:

-   -   Request for quote (RFQ) flow from end user terminals to the        presentation layer of the platform (the ‘E-factory’ portion in        FIG. 1). This allows users to request dealable/executable prices        for spot, forward, and matched swap transactions over the        Internet. Clients use a java trading applet, which will download        on client login.    -   PriceLock Pricing Engine (the ‘Publicised Live Pricing’        element). This provides dealable prices. In the case of spot and        forward FX, these are generated using mathematical algorithms.        The price engine will be used to stream live prices to the user        as well as for pricing individual RFQs. Prices may be        over-ridden by the ING trader.    -   Dealer Intervention (DI)—allows dealers to respond manually to a        price request.    -   Trade Capture—on acceptance of a price, the completed trade will        be passed through MQ to the ING deal capture system Valuta.    -   Pre-trade credit-checking facility utilising ING risk system        RXM.

The solution also makes use of the following generic components providedby the eFactory infrastructure:

-   -   User Profiling system—facilitates user authorisation and        personalisation.    -   Security—2 factor authentication (user/password and secure id).    -   Marketwatch—displays streaming live prices and research (latest        and archive).

The eFX system design allows simultaneous publication of live prices inFX Spot, Forwards and Swaps to proprietary ING web-sites, third partyweb-sites, portals and exchanges. All trades are pre-checked for creditvia an interface to an in-house counterparty risk system, and upon tradeexecution are immediately passed through to a Valuta front-officedeal-capture and position-keeping system, providing a degree ofstraight-through-processing for all internet FX transactions. This willsubsequently reduce middle office headcount requirements, allow moreefficient use of front office resources, and reduce per-tickettransaction costs. The net effect is an increase in market-share throughenhanced presence on an ING web-site and through professional multi-bankportals, and an additional increase in profitability from therealisation of revenue in ‘micro-FX’ transactions, which were previouslynot considered to be cost-effective.

Considerable market advantage is gained by auto-pricing on multi-bankportals, particularly with the proprietary PriceLock™ pricing enginewhich uses an innovative and unique methodology for producing ashort-term forecasted rate, enabling the ING trader to guarantee theperiod of time for which the quoted price will be live or executable.The time period is configurable per currency, per tenor, and per client(some clients may have quicker connections than others e.g. portablephone vs. portal via leased line). Trading windows of guaranteedduration removes the frustration to the customer of prices changing tooquickly for trades to be executed. This unique approach can be extendedto other financial products.

The innovative PriceLock™ pricing engine approach of the presentinvention can be applied to any market where the following hold true:

-   -   1. An offer to buy or sell a commodity is made at one point in        time t₀.    -   2. A resultant agreement to buy or sell that commodity is made        at another distinct point in time t₁.    -   3. Varying supply and/or demand may or may not create price        movement between times t₀ and t₁, e.g. as a result of change in        retail markets and/or wholesale markets, and/or as a result of        speculation.

The invention allows the user (e.g. bank offering the eFX system, asopposed to the end-user or customer) to produce a ‘forecast price’ attime t₀ which is valid until time t₁, where the interval between t₀ andt₁ is determined by the user, and where the user deploys a formula orseveral formulae to produce the ‘forecast price’.

It should be noted that, particularly with respect to internet orwireless trading between two parties, t₀ and t₁ must always be distinctpoints in time, and the time interval between them will be greater thanor equal to the speed of connection over the applicable network.

Additionally, the PriceLock™ system provides the following optionalbenefits:

-   -   1 The ability for the user (including individual traders at the        user) to vary the ‘spread’ (the difference between the commodity        buying price and the selling price at time t₁) according to        market volatility and/or the user's perception and/or        expectation of market volatility.    -   2 The ability for the user to define any mathematical algorithm        deployed in the production of the ‘forecast price’, e.g. for the        purpose of analysing and/or monitoring the risk associated with        the ‘forecast price’.    -   3 The ability for the user to refine any mathematical algorithm        deployed in the production of the ‘forecast price’, e.g. for the        purpose of aligning the risk associated with the ‘forecast        price’ with the user's risk parameters.

Markets where the invention could reasonably be applied includeFinancial Markets, where market forces may create price movement asdescribed, e.g. Fixed Income, Foreign Exchange, Equities, Commodities,Futures, Options and Derivatives.

The invention could also be applied to the energy markets, where theability to forecast, for example, short-term electricity usage couldlead to change in billing structure (e.g. not just ‘economy time’ buthalf-hourly, or shorter, price changes). The invention could also beapplied to the telecommunications market, where the ability to forecast,for example, short-term mobile phone usage could lead to a change inbilling structure (e.g. not just ‘off-peak’ but half-hourly, or shorter,price changes).

The PriceLock™ pricing engine provides a continuous series of 2 wayprocess where spread can be dependent upon market volatility and wheredealer defined parameters control pricing, trading and position risk.

The eFX system design allows the FX dealer to overview and control thecurrent published price whilst monitoring the aggregate position andaverage rate. FIG. 2 is a screen shot showing the window within aconventional web browser that is used by a trader to supervise andcontrol the PriceLock™ quote prices supplied to end-users, in this casefor spot Euro/USD trades. The window includes a ‘time remaining’ clock,here showing that a 4 second trading window still remains before thenext price forecast occurs. The minimum bid price is 0.9071 and askprice is 0.9075; these are the indicative rates generated by thePriceLock™ pricing engine and which are held stable for 6 seconds at theend-users' terminals. Various control functions are also apparent andwill be discussed later. The FIG. 2 screen also shows the current livemid-price being fed to the pricing engine—here 0.9073. Different scalefactors can be selected and applied by the dealer using the ‘scalefactor’ control. Dealers can over-ride the auto-pricing engine,configure their risk parameters and build a personalised spreaddatabase, as shown in FIG. 3.

The screen of a typical FX spot trader at the user (i.e. not anend-user/customer) is shown at FIG. 4. Features offered include:

-   -   Pricing engine data    -   Price audit    -   Price warning    -   Manual over-ride    -   Volatility factoring    -   ‘Panic’ buttons    -   Book passing    -   Position screen    -   Position warning    -   Dealer intervention    -   Market sheet    -   Charting tool

Price information and position responsibility is passed between activecenters on a rotation basis since no center has 24 hour presence.

The PriceLock™ Pricing Engine Itself

The PriceLock™ pricing engine:

-   -   Receives a continually updated record of live market prices from        conventional sources, such as Reuters and EBS, so that whenever        a market price changes, the new price is recorded;    -   Determines the mid-price (p₁ . . . p_(n)) of the live market        prices at regular intervals (t₁ . . . t_(n)) and the range        traded in each period (r₁ . . . r_(n)), as shown in FIG. 5A. In        the spot FX implementation, the engine takes a total of 60        seconds of data, splitting it up into 10 segments, noting the        bid/offer prices at the beginning and end of each segment, and        then calculating the mid-price at each 10 second interval. The        engine then generates a 10 point mid-price curve, which is fed        into the forecasting algorithm to generate the forecast price        which is valid for the next 10 seconds, as explained for the        general case of n intervals (as opposed to 6 intervals) below.        The pricing engine could also forecast bid prices from recent        bid prices and forecasts offer prices from recent offer prices,        to give a 2 way price.    -   Calculates a forecast quote price based upon a number (n) of        regular time intervals such that:        $P_{n + 1} = {\left( {1/\left( {2^{n - 1} - 1} \right)} \right) \times \left\lbrack {{\left( {{3 \times 2^{n - 2}} - 1} \right)P_{n}} - \left( {\sum\limits_{i = 1}^{n - 2}{2^{n - i - 2}P_{n - 1}}} \right) - P_{1}} \right\rbrack}$        where P_(n+1) is the forecast price at time t_(n+1) as derived        from an extrapolation of the changing live market prices P₁ . .        . P_(n) measured at regular time intervals t₁ . . . t_(n).

The forecast price which is calculated expires at the end of the timeperiod (commencing t_(n+1)), at which point the pricing engine isupdated with a live market price and a new forecast price is calculated.The system may also be configured, as is the case for third-partyportals, to produce a forecast price good for t+(2×l) seconds (where lequals latency) using market data divided into equal (t+2l) timesegments, but where the next price is forecast using historical datastarting from only t seconds later (not t+2l). However the process willstill be using a (t+21) time interval to forecast a price good for(t+2l) seconds. This ensures that the customer receives prices valid fort seconds, updating every t seconds. FIG. 5B shows a timing diagramillustrating how at t=60 seconds, forecasting can begin since enoughhistoric data has been collected in the previous minute. Forecasting isrepeated every 6 seconds (t=6 seconds, 12, 18 etc). Assuming a latencyto the end-user of 2 seconds l=2) the first trading window is displayedbetween t=62-68; the second between t=68-74 and the third betweent=74-80 etc. The ‘l’ factor can be different for every portal and indeedcustomer. For in-house systems using high bandwidth connections, ‘l’ canin fact be zero. The eFX forecasting tool's 6 second trading window isconfigurable per instrument (e.g. Euro/USD 1 month swap price isobserved over 10×30 second time segments with the forecast price validfor 30 seconds), and may also be configured per customer.

The optimal forecasting formula typically depends on the pricevolatility characteristics of the particular commodity. Hence, oneformula may be optimal for predicting foreign exchange price movementsduring the two to 10 seconds typical short time interval. The presentintention can be applied to any volatile, price driven commodity,including without limitation stocks, shares, bonds and fixed incomeproducts.

The volatility based spread for this forecast price (r_(n+1)) isestimated based on the highest range traded (r₁ . . . r_(n)) over nintervals. This spread is placed around the forecasted mid-price. In thespot FX implementation, the maximum range recorded in the 10 segments of6 seconds each is used, since this has been found to be a very goodindication of short-term price volatility. It results in a PriceLock™forecasting accuracy of over 99.4% for G7 currencies, which is farhigher than might reasonably be expected. Accuracy is simply the numberof circumstances where there was no price risk experienced, measured asa percentage of the number of calculated prices. A price risk is definedas an instant (typically fractions of a second) where the eFX bid isabove the market offer or the eFX offer is below the market bid, i.e. anarbitrage opportunity.

In case traders might feel the automatically generated maximum range isinappropriate, the eFX system also includes the ability to ‘scale’ thespread (i.e. applying a factor to it, such as 25%, 50%, 120% etc.). Thismight occur if the auto-generated spread is too narrow (i.e. recentprice volatility is very low). Trading with the auto-generated spreadmay mean that trading risk is virtually eliminated, but equally tradingvolumes and hence profit might also be very low, so that a trader mightwish to increase the spread to increase transaction volumes and hencepotential profits.

Additionally, traders may dictate a minimum or a maximum spread to beapplied to the price, dependent upon the instrument and/or amount and/ortenor of the trade (see FIG. 3). The scaled spread is checked againstthese maxima and minima for consistency. Traders can also define ‘cruisecontrol’ limits on an accumulated position, and maximum auto-quoteamounts (again see FIG. 3).

A non-volatility-based spread is also applied by the eFX system; this isa pre-defined spread and takes into account the dealer and salespersonmargins.

Traders are also given the option of manually over-riding the forecastedprice with their own price, valid for their own time period (e.g.‘manual live mid-price’ window in the FIG. 2 Control Sheet window).

The pricing engine is located at single server and control for any givendealer's book can be passed between different dealers across one or morecountries, allowing fully automatic deal-capture (see the ‘pass’ buttonon the dealer Price Control Sheet window, FIG. 2). Trades arepre-checked for credit. Any breach of any trader parameters or creditlimits automatically route a customer request for quote (RFQ) to dealerintervention.

The PriceLock™ system can be used to supply indicative prices which arefar more stable than conventional indicative rates—e.g. a guaranteed 6second window during which the rate will not change, unlike conventionalsystems with prices that can change every second or yet more frequently,depending on market price movements. The indicative quote price isregularly re-generated (as shown in FIG. 5B) so that a fresh quote priceis displayed to an end user once the previous quote price sent to thatend-user has expired at the end of the 6 second window. The fresh quoteprice is sent prior to the end of a trading window by an amount of timecalculated so that the fresh quote price terminates the preceding quoteprice at approximately the time it would self-terminate. FIG. 6 shows a‘Market Sheet’ listing indicative rates of various currency pairs. Thebid/offer price remains stable for 6 second periods.

The PriceLock™ system can also be used to supply execution rates in bothfast quote and reverse auction systems. If an end-user, viewing the FIG.6 ‘Market Sheet’, wishes to trade a particular currency, then he selectsthe desired currency (e.g. by clicking the instrument or bid/offercolumns in the Market Sheet window). Then, an ‘Order Capture’ window, atFIG. 7, is displayed. The end-user enters the appropriate details andselects the ‘price’ button.

FIG. 8 shows the end-user/customer screen after a ‘price’ button hasbeen selected to initiate a RFQ. In this particular example, a RFQ for alarge trade has been input and this has breached the Dealer Parameters,or Risk Limits, and has been sent to manual Dealer Intervention.

The Request Price window indicates to the end-user/customer the statusand normally also the remaining duration of the quote—i.e. the tradingwindow. In this case, the duration field is blank because dealerintervention has been initiated, but normally the field content wouldcount down from 6 seconds to 0 seconds, giving the user a clearindication of the time remaining to trade at the fixed price. Windowsare re-sizeable and columns are interchangeable.

In a reverse auction system (as explained earlier) a bank is asked tosupply a price in 25 seconds time from a start time T₀, with the pricebeing displayed for 5 seconds. The eFX system supplies a quote price atapproximately 24.5 seconds from T₀), assuming 0.5 s latency between thesystem and the requesting portal and zero latency to the end-user,forecasting the price 6 seconds into the future and hence giving therequired 5 second guaranteed trading window when latency is taken intoaccount. Depending upon the functionality offered by the third-partyportal, the end-user's terminal may display a clock which shows theremaining time left during which the end-user may trade. In the case ofthe end-user transacting directly via ING's web-site(s) the end-user'sterminal displays a clock in the form of a countdown bar which shows theremaining time left in which the end user can trade at the quote priceor the elapsed time for which the quote price remains fixed.

The eFX system also offers a complete trade history search for allend-users (as shown in FIG. 9) and audit and analysis data as shown inFIG. 10.

1-42. (canceled)
 42. A pricing engine that automatically forecasts aprice of a tradable commodity so that a quote price can be generatedthat will remain valid for a pre-defined time window.
 43. The pricingengine of claim 42 which forecasts what the price is likely to be at theend of the pre-defined time window and that forecasted price is thenused as the basis for the quote price.
 44. The pricing engine of claim42 which forecasts a mid-price from recent mid-prices, which define themid-point between buy/sell prices.
 45. The pricing engine of claim 42which forecasts bid prices from recent bid prices and forecasts offerprices from recent offer prices, to give a 2 way price.
 46. The pricingengine of claim 42 in which the quote price is sent in response to arequest for a quote and is executable so that a user can trade on thatprice during a trading window of duration less than or equal to thepre-defined time window.
 47. The pricing engine of claim 42 in which thequote price is not sent in response to a request for a quote from anend-user but is automatically generated, indicative only and notexecutable.
 48. The pricing engine of claim 42 in which the quote priceis determined using one or more of the following factors: recent prices,volatility/range of recent prices, deal size, tenor, party credit,scaling factor, tender spread, salesperson spread, network latency. 49.The pricing engine of claim 42 which applies a curve extrapolationalgorithm to forecast the price, the algorithm using a weighted gradientformula to increase the significance of the rate of change of veryrecent prices compared to less recent prices.
 50. The pricing engine ofclaim 49 which operates an algorithm which is functionally equivalent tothe following algorithm:$P_{n + 1} = {\left( {1/\left( {2^{n - 1} - 1} \right)} \right) \times \left\lbrack {{\left( {{3 \times 2^{n - 2}} - 1} \right)P_{n}} - \left( {\sum\limits_{i = 1}^{n - 2}{2^{n - i - 2}P_{n - 1}}} \right) - P_{1}} \right\rbrack}$where P_(n+1) is the forecast price at time t_(n+1) as derived from anextrapolation of the changing live market prices P₁ . . . P_(n) measuredat regular time intervals t₁ . . . t_(n).
 51. The pricing engine ofclaim 44 which applies the widest price range to the forecastedmid-price to generate a spread between buy/sell prices.
 52. The pricingengine of claim 51 in which the spread generated around the forecastedmid-price is modifiable by a scaling factor which can be applied by adealer wishing to apply a correction.
 53. The pricing engine of claim 42in which a scaling factor and/or any other kinds of spreads, correctionsor other modifiers are applied to the forecast price by elements withina transaction platform that are outside of the pricing engine itself.54. The pricing engine of claim 42 in which the pre-defined time windowis calculated to be sufficient to result in a trading window at anend-user terminal that is long enough for the end-user to consider thequote price and successfully trade at that quote price, taking intoaccount network related latencies.
 55. The pricing engine of claim 54 inwhich the trading window is less than the pre-defined time window by anamount equal to the likely time it takes to send the quote price from atransaction platform to an end user terminal and to receive back anorder from that terminal.
 56. The pricing engine of claim 42 in whichthe duration of a pre-defined time window depends on the commodity beingtraded.
 57. The pricing engine of claim 42 in which the duration of apre-defined time window for a given end-user depends on the expected ormonitored network latencies experienced by that end-user.
 58. Thepricing engine of claim 42 in which the duration of a pre-defined timewindow is 10 seconds or less for spot foreign exchange trades.
 59. Thepricing engine of claim 58 in which the duration of a pre-defined timewindow for spot foreign exchange trading is calculated to be longenough, taking into account likely network latencies, to give anend-user an approximately 6 second trade window in which to place anorder.
 60. The pricing engine of claim 42 in which the duration of thepredefined time window depends on the stability of historic prices, suchthat relatively stable commodities such as FX swaps have an associatedtime window as long as 10 minutes and even stabler commodities such asEuro deposit rates have a time window as long as 1 day.
 61. The pricingengine of claim 42 which generates price forecast data in conjunctionwith, or for use with timing data, the timing data enabling an end-userto be shown a clock which shows the remaining time left in which the enduser can trade at the quote price or the elapsed time for which thequote price remains fixed.
 62. The pricing engine of claim 42 in whichthe quote price is time stamped by a transaction platform, with thetiming data being added either by the pricing engine itself or a timersituated externally to the pricing engine.
 63. The pricing engine ofclaim 62 in which time stamping of quote prices enables the remainingduration of a quote price or the exact time of expiry of the quote priceto be displayed on an end-user terminal using a real time clock
 64. Thepricing engine of claim 62 in which the transaction platform accompaniesa quote price data with the duration of the pre-defined time windowand/or trading window.
 65. The pricing engine of claim 42 adapted toapply a spread to the forecast price, and to increase the spread forlonger pre-defined time windows to compensate for the decreased accuracyof the forecasted price and hence the increased risk incurred by acounterparty trading with an end-user at the quote price.
 66. Thepricing engine of claim 42 adapted to apply a spread to the forecastprice, and to increase the spread for smaller trade quantities by anamount calculated to absorb transaction costs and deliver a profit onthe trade.
 67. The pricing engine of claim 42 in which the quote priceis regularly re-generated so that a fresh quote price is displayed to anend user once the previous quote price sent to that end-user has expiredat the end of a trading window.
 68. The pricing engine of claim 67 inwhich the fresh quote price is sent prior to the end of a trading windowby an amount of time calculated so that the trading window of the freshquote price terminates the trading window of the preceding quote priceat approximately the time it would self-terminate.
 69. The pricingengine of claim 42 in which the risk which the entity providing thequote price wishes to incur determines one or more of the following: theduration of the quote price window, the spread applied to the forecastprice.
 70. The pricing engine of claim 42, which is located at singleserver and control for any given dealer's book can be passed betweendifferent dealers across one or more countries.
 71. A method ofproviding a quote price for a tradable commodity, in which the quoteprice (a) has been automatically generated using a forecast pricecalculated by a pricing engine and (b) remains valid for a pre-definedtime window and (c) is supplied to an end-user over a network.
 72. Themethod of claim 71 in which a web portal requests a quote from thepricing engine and displays the executable price to an end-user runninga web browser.
 73. The method of claim 72 in which the web portal is aFX portal.
 74. The method of claim 71 in which the pricing engine is apricing engine as defined in claim
 42. 75. A computer terminaldisplaying a quote price of a tradable commodity, in which the quoteprice (a) is supplied over a network to the terminal and (b) is based ona forecasted price (automatically generated by a pricing engine) thatwill remain valid for a pre-defined time, and in which the terminaldisplays the remaining time for which a given quote price will remainvalid and/or the elapsed time for which the quote price has remainedvalid.
 76. The computer terminal of claim 75 in which the pricing engineis a pricing engine as defined in claim
 42. 77. A method of trading acommodity comprising the steps of: (i) viewing at an end-user terminal aquote price that (a) has been generated using a forecast pricecalculated by a pricing engine and (b) can be traded on so long as atrade order is received at a transaction platform during a pre-definedtime window and (ii) placing an order at the quote price; (iii)receiving the order at a transaction platform within the pre-definedtime window.
 78. The method of claim 77 in which the pricing engine is apricing engine as defined in claim
 42. 79. A system for tradingcommodities comprising (i) a pricing engine which forecasts a price of atradable commodity so that a quote price can be generated that willremain valid for a pre-defined time window; (ii) end-user terminals thatcan display the quote price and allow end-users to place trades and(iii) a network interconnecting the pricing engine and the end-userterminals.
 80. The system of claim 79 in which the pricing engine is apricing engine as defined in claim
 42. 81. Quote price data that (a) hasbeen generated using a forecast price calculated by a pricing engine and(b) remains valid for a pre-defined time window and (c) is supplied toan end-user over a network.
 82. The quote price data of claim 81generated from forecast data by a pricing engine as defined in claim 42.